Relevant test added that covers both this and #231

Hello 👋 Timestamps in OpenPGP only have second precision. I assume that if you'd serialize and parse the key before using it, this issue would go away - which implies that the fix should be something else, i.e. round down the current time when generating keys (and signatures). Though, that would probably need to be done in go-crypto, not gopenpgp.

Both

https://github.com/ProtonMail/go-crypto/blob/58e86b2947569471f4657525aeb6e835e7c7d3eb/openpgp/packet/signature.go#L604-L615

and

https://github.com/ProtonMail/go-crypto/blob/58e86b2947569471f4657525aeb6e835e7c7d3eb/openpgp/packet/public_key.go#L791-L802

Make no requirements about passed and creation time having second prevision. We can use Trunc there, but is it correct way?

The thing is that both pk.CreationTime and sig.CreationTime, when parsed, come from an integer-precision timestamp (see section 3.5 of RFC 4880). So in that case, truncating them should be unnecessary - but when the objects are created directly (e.g. in NewRSAPublicKey, etc), rather than parsed, we should probably truncate the times, for consistency, yeah. Or, alternatively, we could do it in config.Now - that might be simplest.

openpgp.Entity.EncryptionKey is public method which accepts non-truncated time. I suppose there are also other ways to pass nsec time to KeyExpired functions. Truncating there should safe-guard against that getting in.

@twiss ProtonMail/go-crypto#168 like this?